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Abstract.  Over  the  past  few  years,  virtualization  has  been  employed  to  environ¬ 
ments  ranging  from  densely  populated  cloud  computing  clusters  to  home  desktop 
computers.  Security  researchers  embraced  virtual  machine  monitors  (VMMs)  as 
a  new  mechanism  to  guarantee  deep  isolation  of  untrusted  software  components. 
Unfortunately,  their  widespread  adoption  promoted  VMMs  as  a  prime  target  for 
attackers.  In  this  paper,  we  present  HyperCheck,  a  hardware-assisted  tampering 
detection  framework  designed  to  protect  the  integrity  of  VMMs  and,  for  some 
classes  of  attacks,  the  underlying  operating  system  (OS).  HyperCheck  leverages 
the  CPU  System  Management  Mode  (SMM),  present  in  x86  systems,  to  securely 
generate  and  transmit  the  full  state  of  the  protected  machine  to  an  external  server. 
Using  HyperCheck,  we  were  able  to  ferret-out  rootkits  that  targeted  the  integrity 
of  both  the  Xen  hypervisor  and  traditional  OSes.  Moreover,  HyperCheck  is  ro¬ 
bust  against  attacks  that  aim  to  disable  or  block  its  operation.  Our  experimental 
results  show  that  HyperCheck  can  produce  and  communicate  a  scan  of  the  state 
of  the  protected  software  in  less  than  40ms. 


Keywords:  Hypervisor,  Protection  framework.  System  Management  Mode 

1  Introduction 

Hypervisors1  have  become  the  de  facto  standard  in  server  consolidation  because  they 
decrease  the  energy  footprint  and  cost  of  management  of  modern  computing  clusters. 
In  addition,  hypervisors  are  increasingly  used  as  components  to  enforce  system  security 
and  resilience  [22,  28,  16,  38,  21,  36,  31].  This  widespread  adoption  of  virtualization 
has  attracted  the  attention  of  the  attackers  towards  VMM  vulnerabilities.  Indeed,  re¬ 
cently,  there  has  been  a  surge  in  the  reported  vulnerabilities  for  commercial  and  open 
source  hypervisors  [27],  Moreover,  the  number  and  nature  [40,  6]  of  attacks  against  the 
hypervisors  are  poised  to  grow. 

This  increasing  attack  trend  has  spurred  research  towards  reducing  the  hypervisor 
Trusted  Code  Base  (TCB)  of  current  commercial  hypervisors  [26],  Others  developed 
new  specialized  prototype  hypervisors  [36,  24],  However,  having  a  small  code  base  can 
only  limit  the  code  exposure  and  thus  the  attack  surface  of  the  hypervisor  -  it  cannot 
provide  strong  guarantees  about  the  code  integrity  of  all  the  hypervisor  components. 

To  address  these  limitations  and  to  complement  the  existing  protection  mechanisms, 
we  designed  a  hardware-assisted  tampering  detection  framework  called  HyperCheck. 

1  Also  called  Virtual  Machine  Monitors  VMMs 
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HyperCheck  is  designed  to  protect  the  integrity  of  VMMs  and,  for  some  classes  of 
attacks,  the  underlying  operating  system  (OS).  To  achieve  that,  HyperCheck  harnesses 
the  CPU  System  Management  Mode  (SMM)  which  is  present  in  all  x86  commodity 
systems  to  create  a  snapshot  view  of  the  current  state  of  the  CPU  and  memory  registers 
of  the  protected  machine.  This  information  is  securely  and  verifiably  transmitted  using  a 
network  card  to  a  remote  analysis  server.  Using  that  information,  the  analysis  server  can 
identify  any  tampering  by  comparing  the  newly  generated  view  with  the  one  recorded 
when  the  machine  was  initialized.  If  the  two  views  do  not  match,  a  human  operator  is 
notified.  As  shown  in  Figure  1,  HyperCheck  works  at  the  BIOS  level  and  can  protect  the 
software  above  it.  Our  assumptions  are  that  the  attacker  does  not  have  physical  access 
to  the  machine  and  that  the  SMM  BIOS  is  locked  and  thus  cannot  be  altered  during  run. 
We  do  not  explicitly  require  trusted  boot  to  initialize  HyperCheck  [23,  24].  However, 
having  a  machine  equipped  with  trusted  boot  can  prevent  attacks  against  HyperCheck 
that  simulate  a  hardware  reset.  2 

Unlike  previous  work  [30]  that  use  spe¬ 
cialized  PCI  hardware,  we  are  able  to  acquire 
a  complete  view  of  the  target  machine’s  state 
including  the  entire  memory  and  CPU  regis¬ 
ters.  In  addition,  our  approach  is  able  to  thwart 
attacks  aimed  at  disabling,  blocking,  or  even 
taking  over  PCI  devices.  To  evaluate  the  va¬ 
lidity  and  performance  of  our  approach,  we 
implemented  two  prototypes  for  HyperCheck. 

HyperCheck-I  uses  QEMU  [3]  -  a  fully  sys¬ 
tem  emulator  -  to  emulate  the  PCI  NIC,  while 
HyperCheck-II  is  based  on  an  Intel  elOOO  physical  NIC.  Using  our  prototypes,  we  were 
able  to  ferret-out  rootkits  aimed  at  Xen  [11]  hypervisor,  Xen  Domain  0,  Linux,  and  Win¬ 
dows.  Our  experimental  results  indicate  that  HyperCheck  does  not  cause  prohibitive 
performance  overhead  requiring  only  a  few  milliseconds  to  completely  transmit  each 
snapshot. 

In  summary,  we  make  the  following  contributions: 

1.  Designed  a  novel  hardware-assisted  tampering  detection  framework  that  creates  a 
complete  snapshot  of  the  state  of  the  system  with  commercial  hardware  and  no 
modification  to  the  installed  software. 

2.  Implemented  two  prototypes:  one  based  on  QEMU  and  the  other  based  on  the  real 
hardware.  The  latter  has  overhead  in  the  order  of  few  milliseconds.  Using  our  pro¬ 
totype,  we  demonstrate  that  we  can  successfully  detect  rootkits  and  code  integrity 
attacks  against  the  Xen  VMM,  Xen  Domain  0,  Linux,  and  Windows. 

2  Related  work 

Protecting  software  from  integrity  attacks  using  hardware-assisted  techniques  is  not 
new:  researchers  used  a  special-purpose  PCI  device  to  acquire  the  physical  memory 

2  As  we  discuss  in  Section  7,  the  same  can  be  accomplished  using  a  management  interface. 


Fig.  1:  HyperCheck  can  offer  protec¬ 
tion  to  services  running  above  BIOS 
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either  for  rootkit  detection  [30,  2]  or  for  forensic  purpose  [8]  in  the  past.  The  closest 
system  to  our  work  is  Copilot  [30].  Copilot  employed  a  special  PCI  device  to  poll  the 
physical  memory  of  the  host  and  send  it  to  an  admin  station  periodically.  In  Hyper- 
Check,  we  do  not  require  specialized  hardware  -  only  an  out-of-the-box  network  card. 
We  also  offer  a  complete  view  of  the  CPU  state  including  its  registers.  Such  view  is 
important  to  prevent  copy-and-change  attacks  that  can  mislead  the  PCI  card  to  scan  the 
wrong  regions  of  memory  and  report  erroneously  that  the  system  is  not  affected. 

Another  closely  related  work  is  HyperGuard  [33],  Rutkowska  et  al.  suggested  using 
SMM  of  the  x86  CPU  to  monitor  the  integrity  of  the  hypervisors.  Although  we  have 
similar  goals  as  the  HyperGuard  project,  the  use  of  a  network  card  allows  us  to  out¬ 
source  the  analysis  of  the  state  snapshot.  This  results  in  a  drastic  improvement  in  the 
performance  of  the  system  reducing  the  system  busy  time  from  seconds  to  millisec¬ 
onds.  Due  to  its  low  performance  overhead,  HyperCheck  can  also  monitors  the  code 
and  data  of  the  privileged  domain  and  underlying  OSes.  Another  difference  is  that  the 
monitoring  machine  can  be  used  to  detect  the  DoS  attacks  to  the  SMM  code. 

DeepWatch  [6]  also  offers  detection  of  hypervisor  rootkits,  called  virtualization 
malware  in  DeepWatch,  by  using  the  embedded  micro-controller(s)  in  the  chipset.  Deep- 
Watch  is  signature  based  and  used  to  detect  rootkits  relying  on  hardware-assisted  virtu¬ 
alization  technologies  such  as  Intel  VT-d  [18].  Contrary,  HyperCheck  performs  anomaly 
detection  and  thus  can  identify  a  larger  class  of  software  rootkits. 

Flicker  [23]  uses  a  TPM  based  method  to  provide  a  minimum  Trusted  Code  Base 
(TCB),  which  can  be  used  to  detect  the  modification  to  the  kernels.  Flicker  requires 
advanced  hardware  features  such  as  Dynamic  Root  of  Trust  Measurement  (DRTM)  and 
late  launch.  In  contrast,  HyperCheck  uses  the  static  Platform  Configuration  Registers 
(PCRs)  to  secure  the  booting  process.  In  addition,  by  sending  out  the  data,  HyperCheck 
has  a  lower  overhead  on  the  target  machine  compared  to  Flicker.  To  reduce  the  overhead 
of  Flicker,  TrustVisor  [24]  has  a  small  footprint  hypervisor  to  perform  some  cryptogra¬ 
phy  operations.  However,  all  the  legacy  applications  should  be  ported  for  TrustVisor  to 
work.  In  addition,  TrustVisor  requires  DRTM. 

Another  branch  of  research  tries  to  improve  the  security  of  the  hypervisor  by  adding 
hooks  [10]  and  enforcing  security  policies  between  virtual  machines  [34].  These  meth¬ 
ods  are  hypervisor  specific  and  run  as  the  same  level  as  the  hypervisor.  HyperCheck 
monitors  the  hypervisor  state  from  a  lower  level  and  thus,  is  complementary  to  these 
methods. 

Furthermore,  there  is  a  plethora  of  research  aimed  towards  protecting  the  Linux  ker¬ 
nel  [2,  22,  16,  38,  21,  36,  31].  Baliga  [2]  et  al.  use  a  PCI  device  to  acquire  the  memory 
and  automatically  derive  the  kernel  invariance.  Currently,  we  discover  the  kernel  invari¬ 
ance  manually  but  we  could  employ  their  techniques  directly  and  without  modifications. 
Litty  [22]  et  al.  developed  a  technique  to  discover  the  address  of  key  data  structures  that 
are  instantiated  during  run-time  by  relying  on  processor  hardware  and  executable  file 
specifications.  But  they  also  rely  on  the  integrity  of  the  underlying  hypervisors.  Hyper¬ 
Check  first  obtains  the  virtual  addresses  of  those  symbols  through  the  symbol  file,  but 
then  calculates  the  physical  addresses  through  CPU  registers.  Therefore,  HyperCheck 
can  get  the  correct  view  of  the  system  memory  even  if  the  underlying  OS  or  hypervisor 
is  compromised  and  page  tables  are  altered.  Other  existing  research  [38,  21,  36,  31], 
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including  work  by  Jiang  et  al. ,  depend  on  the  integrity  of  the  hypervisor  to  protect  the 
kernel.  Our  work  is  complementary  and  can  be  employed  as  a  meta-protection  mecha¬ 
nism  to  guard  the  integrity  of  OS-level  defenses.  A  lot  of  recent  work  has  gone  towards 
using  SMM  to  generate  efficient  rootkits  [39,  5,  15,  12].  These  rootkits  can  be  used 
either  to  get  root  privilege  or  as  a  key-stroke  loggers.  We  use  SMM  to  offer  integrity 
protection  by  monitoring  the  state  of  hypervisors  and  operating  systems. 


3  Threat  model 

3.1  Background  of  System  Management  Mode 

System  Management  Mode  (SMM)  was  introduced  in  the  Intel386  SL  and  Intel486  SL 
processors.  It  became  a  standard  IA-32  feature  in  the  Pentium  [20]  processor.  SMM  is  a 
separate  CPU  mode  besides  the  protected  and  real  mode.  The  original  purpose  of  SMM 
was  to  provide  a  transparent  mechanism  for  implementing  platform  specific  functions 
such  as  power  management  and  system  security.  The  processor  enters  SMM  when  the 
external  SMM  interrupt  pin  (SMI#)  is  activated  or  a  SMI  is  received  from  the  advanced 
programmable  interrupt  controller  (APIC)  [20]. 

In  SMM,  the  processor  switches  to  a  separate  address  space,  called  system  manage¬ 
ment  RAM  (SMRAM).  In  addition,  all  hardware  context  of  the  currently  running  code 
is  saved  in  SMRAM.  Then,  the  CPU,  being  in  SMM,  executes  transparently  code  that 
is  usually  a  part  of  BIOS  and  resides  in  SMRAM.  The  SMRAM  can  be  made  inacces¬ 
sible  from  other  CPU  operating  modes.  Therefore,  it  can  act  as  trusted  storage,  sealed 
from  being  accessed  from  any  device  or  even  the  CPU  (while  not  in  SMM  mode).  In 
HyperCheck,  we  modify  the  SMM  code  to  execute  our  monitoring  functions.  This  mod¬ 
ification  of  SMM  code  can  be  integrated  into  the  BIOS.  Another  way  is  to  use  a  trust 
boot  mechanism  or  a  management  interface  to  upload  the  code  to  SMM  (when  SMRAM 
is  not  locked)  and  then  lock  the  SMRAM.  Upon  returning  from  SMM,  the  processor  is 
placed  back  into  its  state  prior  to  enter  SMM. 

3.2  Attacker’s  capabilities 

We  assume  that  the  adversary  has  following  capabilities:  she  is  able  to  exploit  vulner¬ 
abilities  in  any  software  running  in  the  machine  after  bootup.  This  includes  the  VMM 
and  all  of  its  privileged  components.  For  instance,  the  attacker  can  compromise  a  guest 
domain  and  escape  to  the  privileged  domain.  In  Xen  3.0.3,  pygrub  [9]  allows  local  users 
with  elevated  privileges  in  the  guest  domain  (Domain  U)  to  execute  arbitrary  commands 
in  Domain  0  via  a  crafted  grub.conf  file  [25].  Also,  the  attacker  can  modify  the  hypervi¬ 
sor  code  or  data  using  any  known  or  zero-day  attacks.  For  instance,  the  DMA  attack  [40] 
hijacks  a  device  driver  to  perform  unauthorized  DMA  to  the  hypervisor’s  code  or  data. 

3.3  General  Assumptions 

The  attacker  cannot  tamper  with,  or  replace  the  installed  PCI  NIC  with  a  malicious  NIC 
using  the  same  driver  interface.  Also,  if  the  SMM  code  is  integrated  with  BIOS,  we 
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assume  the  SMRAM  is  properly  setup  by  BIOS  upon  boot  time.  If  the  SMM  code  is  not 
included  in  the  BIOS,  it  has  to  be  reliably  uploaded  to  the  SMRAM  during  boot.  This 
can  be  done  by  either  using  trusted  boot  or  using  the  management  interface  to  bootstrap 
the  computer.  In  this  case,  to  initialize  the  SMM  code,  a  trusted  bootstrap  mechanism 
has  to  be  employed.  The  SMRAM  is  locked  once  it  is  properly  set  up.  Once  it  is  locked, 
we  assume  it  cannot  be  subverted  by  the  attacker  (an  assumption  supported  by  current 
hardware).  Attacks  that  attempt  to  modify  the  SMM  code  [41,  13,  14]  are  beyond  the 
scope  of  this  paper. 


3.4  In-scope  Attacks 

HyperCheck  aims  to  detect  the  in-memory,  Ring-0  level  (hypervisor  or  general  OS) 
rootkits  and  rootkits  in  privileged  domains  of  hypervisors.  A  rootkit  is  a  set  of  programs 
and  code  that  allows  a  permanent  or  consistent,  undetectable  presence  on  a  computer 
[19],  One  kind  of  rootkits  only  modifies  the  memory  and/or  registers  and  runs  in  the 
kernel  level.  For  example,  the  idt-hook  rootkit  [1]  modifies  the  interrupt  descriptor  table 
(IDT)  in  the  memory  and  then  gains  the  control  of  the  complete  system.  An  stealthier 
version  of  the  idt-hook  rootkit  could  keep  the  original  IDT  unchanged  by  copying  it  to  a 
new  location  and  altering  it.  Next,  the  attacker  could  change  the  IDTR  register  to  point 
to  the  new  location.  When  it  comes  to  the  hypervisor  level  rootkit,  there  is  yet  another 
kernel:  the  hypervisor  kernel  which  runs  underneath  the  operating  system  kernel.  There 
are  existing  methods  to  detect  in-memory,  kernel-level  rootkits.  We  try  to  bridge  this 
gap  by  introducing  HyperCheck. 


3.5  Limitations 

Currently,  our  analysis  cannot  protect  against  attacks  that  modify  dynamic  data.  There 
are  two  types  of  threats:  modification  to  the  dynamically  generated  function  pointers 
and  return-oriented  attacks.  In  these  attacks,  the  control  flow  is  redirected  to  memory 
location  controlled  by  the  attacker.  There  are  techniques  to  thwart  such  attacks:  the  non¬ 
executable  bit  in  new  CPUs  and  Address  Space  Layout  Randomization  to  name  a  few. 
HyperCheck  can  leverage  and  integrate  those  techniques  to  provide  full  protection  but 
it  was  not  part  of  our  implementation  in  this  paper.  Having  said  that,  we  can  still  detect 
the  presence  of  the  malfease  if  it  tries  to  interfere  with  the  VMM  code  or  statically 
defined  function  pointer. 


4  System  Architecture 

HyperCheck  is  composed  of  three  key  components:  the  physical  memory  acquiring 
module,  the  analysis  module  and  the  CPU  register  checking  module.  The  memory  ac¬ 
quiring  module  reads  the  contents  of  the  physical  memory  of  the  protected  machine 
and  sends  them  to  the  analysis  module.  Then,  the  analysis  module  checks  the  memory 
contents  and  verifies  if  anything  is  altered.  The  CPU  register  checking  module  reads 
the  registers  and  validates  their  integrity.  The  overall  architecture  of  HyperCheck  is 
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Fig.  2:  The  architecture  of  HyperCheck 


shown  in  Figure  2.  Before  introducing  the  key  components,  we  first  describe  our  design 
principles. 

Our  main  design  principle  is  that  HyperCheck  should  not  rely  on  any  software  run¬ 
ning  on  the  machine  except  the  boot  loader.  Since  the  software  may  be  compromised, 
one  cannot  trust  even  the  hypervisor.  Therefore,  we  use  hardware  -  a  PCI  Ethernet  card 
-  as  a  memory  acquiring  module  and  SMM  to  read  the  CPU  registers.  Usually,  Ethernet 
cards  are  PCI  devices  with  bus  master  mode  enabled  and  are  able  to  read  the  physical 
memory  through  DMA,  which  does  not  need  help  from  CPU.  SMM  is  an  independent 
operating  mode  and  could  be  made  inaccessible  from  protected  mode  which  is  what  the 
hypervisor  and  privileged  domains  run  in. 

Previous  researchers  only  used  PCI  devices  to  read  the  physical  memory.  However, 
CPU  registers  are  also  important  because  they  define  the  location  of  active  memory 
used  by  the  hypervisor  or  an  OS  kernel  such  as  CR3  and  IDTR  registers.  Without  these 
registers,  the  attacker  can  launch  a  copy-and-change  attack.  It  means  the  attacker  copies 
the  memory  to  a  new  location  and  modifies  it.  Then  the  attacker  updates  the  register  to 
point  to  the  new  location.  PCI  devices  cannot  read  the  CPU  registers,  thereby  failing  to 
detect  this  kind  of  attacks.  By  using  SMM,  HyperCheck  can  examine  the  registers  and 
report  the  suspicious  modifications. 

Furthermore,  HyperCheck  uses  the  CR3  register  to  translate  the  virtual  addresses 
used  by  the  kernel  to  the  physical  addresses  captured  by  the  analysis  module.  Since  the 
acquiring  module  relies  on  the  physical  address  to  read  the  memory,  HyperCheck  needs 
to  find  the  physical  addresses  of  the  protected  hypervisor  and  privileged  domain.  For 
that  purpose,  HyperCheck  checks  both  symbol  hies  and  CPU  registers.  From  symbol 
hies,  HyperCheck  can  read  the  virtual  addresses  of  the  target  memory.  Then,  Hyper¬ 
Check  utilizes  CPU  registers  to  hnd  the  physical  addresses  corresponding  to  the  vir¬ 
tual  ones.  Previous  systems  only  used  the  symbol  hies  to  read  the  virtual  addresses 
and  calculate  the  physical  addresses.  Such  systems  can  not  detect  attacks  that  modify 
page  tables  and  leave  the  original  memory  untouched.  Another  possible  way  to  get  the 
physical  addresses  without  using  registers,  is  to  scan  the  entire  physical  memory  and 
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use  pattern  matching  to  find  all  potential  targets.  However,  this  method  is  not  scalable 
or  even  efficient  especially  since  hypervisors  and  operating  system  kernels  have  small 
memory  footprint. 

4.1  Acquiring  the  physical  memory 

In  general,  there  are  two  ways  to  acquire  the  physical  memory:  a  software  method 
and  a  hardware  one.  The  former  uses  the  interface  provided  by  the  OS  or  the  hyper¬ 
visor  to  access  the  physical  memory,  such  as  /dev/kmem  on  Linux  [7]  or  \Device 
\PhysicalMemory  on  Windows  [37].  This  method  relies  on  the  integrity  of  the  under¬ 
lying  operating  system  or  the  hypervisor.  If  the  operating  system  or  the  hypervisor  is 
compromised,  the  malware  may  provide  a  false  view  of  the  physical  memory.  Moreover, 
these  interfaces  to  access  memory  can  be  disabled  in  future  versions  of  the  operating 
systems.  In  contrast,  the  hardware  method  uses  a  PCI  device  [8,  30]  or  other  kinds  of 
hardware  [6].  The  hardware  method  is  more  reliable  because  it  depends  less  on  the 
integrity  of  the  operating  system  or  the  hypervisor. 

We  choose  the  hardware  method  to  read  the  physical  memory.  There  are  also  multi¬ 
ple  options  for  the  hardware  components  such  as  a  PCI  device,  a  FireWire  bus  device  or 
customized  chipset.  We  selected  to  use  a  PCI  device  because  it  is  the  most  commonly 
used  hardware.  Moreover,  existing  commercial  Ethernet  cards  need  drivers  to  func¬ 
tion.  These  drivers  normally  run  in  the  operating  system  or  the  driver  domain,  which 
are  vulnerable  to  the  attacks  and  may  be  compromised  in  our  threat  model.  To  avoid 
this  problem,  HyperCheck  puts  these  drivers  into  the  SMM  code.  Since  the  SMRAM 
memory  is  going  to  be  locked  after  booting,  it  will  not  be  modified  by  the  attacker.  In 
addition,  to  prevent  the  attacker  from  using  a  malicious  NIC  driver  in  the  OS  to  spoof 
the  SMM  driver,  we  use  a  secret  key.  The  key  is  obtained  from  the  monitor  machine 
when  the  target  machine  is  booting  up  and  then  stored  in  the  SMRAM.  The  key  then 
is  used  as  a  random  seed  to  selectively  hash  a  small  portion  of  the  data  to  avoid  data 
replay  attacks. 

Another  class  of  attacks  is  denial  of  service(DoS)  attacks.  Such  attacks  aim  to  stop 
or  disable  the  device.  For  instance,  according  to  ACPI  [17]  specification,  every  PCI 
device  supports  D3  state.  This  means  that  an  ACPI-compatible  device  can  be  suspended 
by  an  attacker  who  takes  over  the  operating  system:  ACPI  was  designed  to  allow  the 
operating  system  to  control  the  state  of  the  devices.  Of  course,  the  OS  is  not  a  trusted 
component  in  our  threat  model.  Therefore,  one  possible  attack  is  to  selectively  stop  the 
NIC  without  stopping  any  other  hardware.  To  prevent  ACPI  DoS  attacks,  we  need  an 
out-of-band  mechanism  to  verify  that  the  PCI  card  is  not  disabled.  The  remote  server 
that  receives  the  state  snapshots  plays  that  role. 

4.2  Translating  the  physical  memory 

In  practice,  there  is  a  semantic  gap  between  the  physical  memory  that  we  monitor  and 
the  virtual  memory  addressing  used  by  the  hypervisor.  To  translate  the  physical  mem¬ 
ory,  the  analysis  module  must  be  aware  of  the  semantics  of  the  physical  memory  layout 
depends  on  the  specific  hypervisor  we  monitor.  On  the  other  hand,  the  acquiring  module 
may  support  many  different  analysis  modules  with  no  or  small  modifications. 
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The  current  analysis  module  depends  on  three  properties  of  the  kernel  memory: 
linear  mapping,  static  nature  and  persistence.  Linear  mapping  means  the  kernel  (OS  or 
hypervisor)  memory  is  linearly  mapped  to  physical  memory  and  the  physical  addresses 
are  fixed.  For  example,  on  x86  architecture,  the  virtual  memory  of  Xen  hypervisor  is 
linearly  mapped  into  the  physical  memory.  Therefore,  in  order  to  translate  the  physical 
address  to  a  given  virtual  address  in  Xen,  we  have  to  subtract  the  virtual  address  from  an 
offset.  In  addition.  Domain  0  of  Xen  is  also  linear  mapped  to  the  physical  memory.  The 
offset  for  Domain  0  is  different  on  different  machines  but  remains  the  same  on  a  given 
machine.  Moreover,  other  operating  system  kernels,  such  as  Windows  [35],  Linux  [4] 
or  OpenBSD  [12],  also  have  this  property  when  they  are  running  directly  on  the  real 
hardware. 

Static  nature  means  the  contents  of  the  monitoring  part  of  the  hypervisor  have  to  be 
static.  If  the  contents  are  changing,  then  there  might  be  a  time  window  between  the  CPU 
changing  the  contents  and  our  acquiring  module  reading  them.  This  may  result  in  in¬ 
consistency  for  analysis  and  verification.  Persistence  property  means  the  memory  used 
by  hypervisors  will  not  be  swapped  out  to  the  hard  disk.  If  the  memory  is  swapped  out, 
then  we  cannot  identify  and  match  any  content  by  only  reading  the  physical  memory. 
We  would  have  to  read  the  swap  file  on  the  hard  disk. 

The  current  version  of  HyperCheck  relies  on  these  three  properties  (linear  map¬ 
ping,  static  nature  and  persistence  )  to  work  correctly.  Besides  the  Xen  hypervisor,  most 
operating  systems  hold  these  three  properties  too. 

4.3  Reading  and  verifying  the  CPU  registers 

Since  the  Ethernet  card  cannot  read  the  CPU  registers,  we  must  use  another  method 
to  read  them.  Again,  there  are  software  and  hardware  based  methods.  For  software 
method,  one  could  install  a  kernel  module  in  the  hypervisor  and  then  it  could  obtain 
registers  by  reading  from  the  CPU  directly.  However,  this  is  vulnerable  to  the  rootk- 
its,  which  can  potentially  modify  the  kernel  module  or  replace  it  with  a  fake  one.  For 
hardware  method,  one  could  use  a  chipset  to  obtain  registers. 

We  choose  to  use  SMM  in  x86  CPU  which  is  similar  to  a  hardware  method.  As  we 
mentioned  earlier,  SMM  is  a  different  CPU  mode  from  the  protected  mode  which  the 
hypervisor  or  the  operating  system  reside  in.  When  CPU  switches  to  SMM,  it  saves  the 
register  context  in  the  SMRAM.  The  default  SMRAM  size  is  64K  Bytes  beginning  at  a 
base  physical  address  in  physical  memory  called  the  SMBASE.  The  SMBASE  default 
value  following  a  hardware  reset  is  0x30000.  The  processor  looks  for  the  first  instruction 
of  the  SMI  handler  at  the  address  [SMBASE  +  0x8000],  It  stores  the  processor’s  state 
in  the  area  from  [SMBASE  +  OxFEOO]  to  [SMBASE  +  OxFFFF]  [20],  In  SMM,  if  SMI 
handler  issues  rsm  instruction,  the  processor  will  switch  back  to  the  previous  mode 
(usually  it  is  protected  mode).  In  addition,  the  SMI  handler  can  still  access  I/O  devices. 
HyperCheck  verifies  the  registers  in  SMM  and  reports  the  result  by  sending  it  via  the 
Ethernet  card  to  the  monitor  machine.  HyperCheck  focuses  on  monitoring  two  registers: 
IDTR  and  CR3.  IDTR  should  never  change  after  system  initialization.  For  CR3,  SMM 
code  can  use  it  to  translate  the  physical  addresses  of  the  hypervisor  kernel  code  and 
data.  The  offsets  between  physical  addresses  and  virtual  ones  should  never  change  as 
we  discussed  in  Section  4.2. 
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5  Implementation 

We  implemented  two  prototypes  for  HyperCheck:  HyperCheck-I  is  using  QEMU  full 
system  emulation  while  HyperCheck-II  is  running  on  a  physical  machine.  We  first 
developed  HyperCheck-I  for  quick  prototyping  and  debugging.  To  measure  the  over¬ 
all  system  performance,  we  implemented  HyperCheck-II  on  non-virtualized  hardware. 
Both  of  them  utilize  the  Intel  elOOO  Ethernet  card  as  the  acquiring  module. 

In  HyperCheck-I,  the  target  machine  is  as  a  virtual  machine  that  uses  QEMU.  The 
analysis  module  runs  on  the  host  operating  system  of  QEMU.  For  the  acquiring  module, 
we  placed  a  small  NIC  driver  into  the  SMM  of  the  target  machine.  Using  the  driver,  we 
can  program  the  NIC  to  transmit  the  contents  of  physical  memory  as  an  Ethernet  frame. 
On  the  monitoring  machine,  an  analysis  module  receives  the  packet  from  the  network. 
The  analysis  module  compares  contents  of  the  physical  memory  with  the  original  (ini¬ 
tial)  versions.  If  a  new  snapshot  of  the  memory  contents  is  different  from  the  original 
one,  the  module  will  report  the  event  to  a  system  operation  who  can  decide  how  to  pro¬ 
ceed.  Moreover,  another  small  program  runs  in  the  SMM  and  collects  and  sends  out  the 
CPU  registers  also  via  the  Ethernet  card. 

For  HyperCheck-II,  we  used  two  physical  machines:  one  as  the  target  and  the  other 
as  the  monitor.  On  the  target  machine,  we  installed  Xen  3. 1  natively  and  used  the  phys¬ 
ical  Intel  elOOO  Ethernet  card  as  the  acquiring  module.  Also,  we  modified  the  default 
SMM  code  on  the  target  machine  to  enable  our  system  similarly  to  our  QEMU  imple¬ 
mentation.  The  analysis  module  runs  on  the  monitor  machine  and  is  the  same  as  the  one 
in  HyperCheck-I.  HyperCheck-H  is  mainly  used  for  performance  measurement. 

As  we  mentioned  earlier,  we  used  QEMU  for  HyperCheck-I.  QEMU  is  suitable  for 
debugging  potential  implementation  problems.  However,  it  comes  with  two  drawbacks. 
First,  the  throughput  of  a  QEMU  network  card  is  much  lower  than  a  real  NIC  device. 
For  our  QEMU  based  prototype,  the  network  card  throughput  is  approximately  lOMB/s, 
although  Gigabit  Ethernet  cards  are  common  in  practice.  Second,  the  performance  mea¬ 
surement  on  QEMU  may  not  reflect  the  real  world  performance.  HyperCheck-II  help 
us  overcome  these  problems. 


5.1  Memory  Acquiring  module 

The  main  task  to  implement  the  acquiring  module  is  to  port  the  elOOO  network  card 
driver  into  SMM  to  scan  the  memory  and  send  it  out.  Normally,  SMM  code  is  one  part 
of  BIOS.  Since  we  don’t  have  the  source  code  of  the  BIOS,  we  used  the  method  similar 
to  the  one  mentioned  in  [5]  to  modify  the  default  SMM  code.  Basically,  it  writes  the 
SMM  code  in  16bit  assembly  and  uses  a  user  level  program  to  open  the  SMRAM  and 
copy  the  assembly  code  to  the  SMRAM. 

To  overcome  the  limitations  of  [5],  we  divided  the  elOOO  driver  into  two  parts:  ini¬ 
tialization  and  data  transfer.  The  initialization  part  is  complex  and  very  similar  to  the 
Linux  driver.  The  communication  part  is  simpler  and  different  from  the  Linux  driver. 
Therefore,  we  modified  the  existing  Linux  elOOO  driver  to  initialize  the  network  card 
and  only  program  the  transferring  part  in  assembly.  The  elOOO  driver  on  Linux  is 
changed  to  only  initialize  the  NIC  but  does  not  send  out  any  packet.  The  assembly 
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code  is  compiled  to  an  ELF  object  file.  Next,  we  wrote  a  small  loader  which  can  parse 
the  ELF  object  file  and  load  the  code  and  data  to  the  SMM. 

For  this  implementation,  the  NIC  driver  is  ported  to  the  SMM,  the  next  step  is 
to  modify  the  driver  to  scan  the  memory  and  send  them  out.  HyperCheck  uses  two 
transmission  descriptors  per  packet,  one  for  the  header  and  the  other  for  the  data.  The 
content  of  the  header  should  be  predefined.  Since  the  NIC  is  already  initialized  by 
the  OS,  the  driver  in  SMM  has  only  to  prepare  the  descriptor  table  and  write  it  to  the 
Transmit  Descriptor  Tail  (TDT)  register  of  the  NIC.  The  NIC  will  send  the  packet  to  the 
monitoring  machine  using  DMA.  The  NIC  driver  in  SMM  prepares  the  header  data  and 
let  the  descriptor  point  to  this  header.  For  the  payload,  the  descriptor  is  directly  pointed 
to  the  address  of  the  memory  that  needs  to  be  scanned.  In  addition,  el 000  NIC  supports 
CRC  offloading. 

To  prevent  replay  attacks,  a  secret  key  is  transferred  from  the  monitor  machine  to 
the  target  machine  upon  booting.  The  key  is  used  to  create  a  random  seed  to  selectively 
hash  the  data.  If  we  hash  the  entire  data  stream,  the  performance  impact  may  be  high. 
To  reduce  the  overhead,  we  use  the  secret  key  as  a  seed  to  generate  one  big  random 
number  used  for  one-time  pad  encryption  and  another  set  of  serial  random  numbers. 
The  serial  of  random  numbers  are  used  as  the  indexes  of  the  positions  of  the  memory 
being  scanned.  Then,  the  content  at  these  positions  are  XORed  with  the  one-time  pad 
with  the  same  length  before  starting  NIC  DMA.  After  the  transmission  is  done,  the 
memory  content  is  XORed  again  to  restore  the  original  value. 

The  NIC  driver  also  checks  the  loop-back  setting  of  the  device  before  sending  the 
packet.  To  further  guarantee  the  data  integrity  .the  SMM  NIC  driver  stays  in  the  SMM 
until  all  the  packet  is  written  to  the  internal  FIFO  of  the  NIC,  and  add  64KB  more  data 
to  the  end  to  flush  the  internal  FIFO  of  the  NIC.  Therefore,  the  attacker  cannot  use  loop- 
back  mode  to  get  the  secret  key  or  peek  into  the  internal  NIC  buffer  through  debugging 
registers  of  the  NIC. 

5.2  Analysis  module 

On  the  monitoring  machine,  a  dedicated  network  card  is  connected  with  the  acquiring 
module.  The  operating  system  of  the  monitoring  machine  was  CentOS  5.3.  We  run 
tcpdump  to  filter  the  packets  from  the  acquiring  module;  the  output  of  tcpdump  is 
sent  to  the  analysis  module.  The  analysis  module  written  in  a  Perl  script  reads  the  input 
and  checks  for  any  anomalies.  The  analysis  module  first  recovers  the  contents  using  the 
same  secret  key.  After  that,  it  compares  every  two  consecutive  memory  snapshots  bit  by 
bit.  If  they  are  different,  the  analysis  module  outputs  an  alert  on  the  console,  as  we  are 
checking  the  persistent  and  static  portion  of  the  hypervisor  memory.  The  administrator 
can  then  decide  whether  it  is  a  normal  update  of  the  hypervisor  or  an  intrusion.  Note  that 
during  the  system  boot  time,  the  contents  of  those  control  data  and  code  are  changing. 

Currently,  the  analysis  module  can  check  the  integrity  of  the  control  data  and  code. 
The  control  data  includes  IDT  table,  hypercall  table  and  exception  table  of  Xen,  and 
the  code  is  the  code  part  of  Xen  hypervisor.  To  find  out  the  physical  address  of  these 
control  tables,  we  use  Xen .  map  symbol  file.  First,  we  find  the  virtual  addresses  of 
idt_table,  hypercall_table  and  exceptionJable.  The  physical  address  of  these 
symbols  is  virtuaLaddress  —  OxffOO.OOOO  on  x86-32  architecture  with  PAE.  The  address 
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of  Xen  hypervisor  code  is  between  _stext  and  _etext.  HyperCheck  can  also  mon¬ 
itor  the  control  data  and  codes  of  Domain  0.  This  includes  the  system  call  table  and 
the  code  part  of  Domain  0  (a  modified  Linux  2.6.18  kernel).  The  kernel  of  Domain  0 
is  also  linearly  mapped  to  the  physical  memory.  We  use  a  kernel  module  running  in 
Domain  0  to  compute  the  exact  offset.  On  our  test  machine,  the  offset  is  0x83000000. 
Note  that,  there  is  no  IDT  table  for  Domain  0,  because  there  is  only  one  such  table  in 
the  hypervisor.  We  input  these  parameters  to  the  acquiring  module  to  improve  the  scan 
efficiency. 

Note  that  these  control  tables  are  critical  to  system  integrity.  If  their  contents  are 
modified  by  any  malware,  it  can  potentially  run  arbitrary  code  in  the  hypervisor  level, 
i.e.  the  most  privileged  level.  An  antivirus  software  or  intrusion  detection  system  that 
runs  in  Domain  0  is  difficult  or  unable  to  detect  this  hypervisor  level  malware  because 
they  rely  on  the  hypervisor  to  provide  the  correct  information.  If  the  hypervisor  itself  is 
compromised,  it  may  provide  fake  information  to  hide  the  malware.  The  checking  for 
the  code  part  of  the  hypervisor  enables  HyperCheck  to  detect  the  attacks  which  do  not 
modify  the  control  table  but  just  modify  the  code  invoked  by  those  tables. 

5.3  CPU  register  checking  module 

HyperCheck  uses  SMM  code  to  acquire  and  verify  CPU  registers.  In  a  product,  the  SMI 
handler  should  be  integrated  into  BIOS.  Or  it  can  be  set  up  during  the  system  boot  time. 
This  requires  the  bootstrap  to  be  protected  by  some  trusted  bootstrap  mechanism.  In 
addition,  most  chipsets  provide  a  function  to  lock  the  SMRAM.  Once  it  is  locked,  SMM 
handler  cannot  be  changed  until  reboot.  Therefore,  the  SMRAM  should  be  locked  once 
it  is  set  up.  In  our  prototype,  we  used  the  method  mentioned  in  Section  5.1  to  modify 
the  default  SMM  code. 

There  are  three  steps  for  CPU  register  checking:  1)  triggering  SMI  to  enter  SMM; 
2)  checking  the  registers  in  SMM;  3)  reporting  the  result.  SMI  is  a  hardware  interrupt 
and  can  only  be  triggered  by  hardware.  Normally,  I/O  Controller  Hub  (ICH),  also  called 
Southbridge,  defines  the  events  to  trigger  SMI.  For  HyperCheck-I,  the  QEMU  emulates 
Intel  82371  SB  chip  as  the  Southbridge.  It  supports  some  device  idle  events  to  generate 
SMI.  SMI  is  often  used  for  power  management,  and  Southbridge  provides  some  timers 
to  monitor  the  state  of  a  device.  If  that  device  remains  idle  for  a  long  time,  it  will  trigger 
SMI  to  turn  off  that  device.  The  resolutions  of  these  timers  are  typically  one  second. 
However,  on  different  motherboard,  the  method  to  generate  the  SMI  may  be  different. 
Therefore,  we  employ  the  Ethernet  card  to  trigger  the  SMI  event. 

For  the  register  checking,  HyperCheck  monitors  IDTR  and  CR3  registers.  The  con¬ 
tents  of  IDTR  should  never  change  after  system  boot.  The  SMM  code  just  reads  this 
register  by  sidt  instruction.  HyperCheck  uses  CR3  to  find  out  the  physical  addresses 
of  hypervisor  kernel  code  and  data  given  their  virtual  addresses.  Essentially,  it  walks 
through  all  the  page  tables  as  a  hardware  Memory  Management  Unit  (MMU)  does. 
Note  that  offset  between  the  virtual  address  and  the  physical  address  of  hypervisor  ker¬ 
nel  code  and  data  should  never  change.  For  example,  it  is  OxffOOOOOO  for  Xen  32bit 
with  PAE.  The  Domain  0  has  the  same  property.  The  SMM  code  requires  the  virtual 
address  range  as  the  input  (this  can  be  obtained  through  the  symbol  file  and  send  to  the 
SMM  in  the  boot  time)  and  afterwards  check  their  physical  addresses.  If  any  physical 


12 


Jiang  Wang,  Angelos  Stavrou,  and  Anup  Ghosh 


address  is  not  equal  to  virtual  address  -  offset,  this  signifies  a  possible  attack.  The  SMM 
code  reports  the  result  of  this  checking  via  the  Ethernet  card.  The  assembly  code  of  it 
is  just  67  LOC. 

The  SMM  code  uses  the  Ethernet  card  to  report  the  result.  Without  the  Ethernet 
card,  it  is  difficult  to  send  the  report  reliably  without  stopping  the  whole  system.  For 
example,  the  SMM  code  could  write  the  result  to  a  fixed  address  of  physical  memory. 
But  according  to  our  threat  model,  the  attacker  has  access  to  that  physical  memory  and 
can  easily  modify  the  result.  Or  the  SMM  code  could  write  it  to  the  hard  disk.  Again, 
this  can  be  altered  by  the  attacker  too.  Since  security  cannot  relies  on  the  obscurity,  the 
only  way  left  without  a  network  card  is  to  stay  in  the  SMM  mode  and  put  the  warning 
message  on  the  screen.  This  is  reliable,  but  the  system  in  the  protected  mode  becomes 
completely  frozen.  Sometimes,  it  may  not  be  desirable,  and  could  be  abused  by  the 
attacker  to  launch  Denial  of  Service  attacks. 

5.4  HyperCheck-II 

In  HyperCheck-II,  the  main  difference  from  HyperCheck-I  is  the  acquiring  module.  We 
ported  the  SMM  NIC  driver  from  QEMU  to  a  physical  machine.  Both  of  them  have 
the  same  model  of  the  NIC:  82540EM  Gigabit  Ethernet  card.  However,  the  SMM  NIC 
driver  from  the  QEMU  VM  does  not  work  on  the  physical  machine.  And  it  took  one  of 
the  author  one  week  to  debug  the  problem.  Finally,  we  find  out  that  the  main  difference 
between  a  QEMU  VM  and  the  physical  machine  (Dell  Optiplex  GX  260)  is  that  the 
NIC  can  access  the  SMRAM  in  a  QEMU  VM  while  it  cannot  on  the  physical  machine. 
For  HyperCheck-I  SMM  NIC  driver,  the  TX  descriptor  is  stored  in  the  SMRAM  and  it 
works  well.  For  HyperCheck-H,  the  NIC  cannot  read  the  TX  descriptor  in  the  SMRAM 
and  therefore  does  not  transmit  any  data. 

To  solve  this  problem,  we  reserved  a  portion  of  physical  memory  by  adding  a  boot 
parameter:  mem=5  00M  to  the  Xen  hypervisor  or  Linux  kernel.  Since  the  total  physical 
memory  on  the  physical  machine  is  512MB,  we  reserved  12MB  for  HyperCheck  by 
using  mem  parameter.  This  12MB  is  used  to  store  the  data  used  by  SMM  NIC  and 
the  TX  descriptor  ring.  We  also  modified  the  loader  to  be  a  kernel  module;  it  calls 
ioremap  ( )  to  map  the  physical  memory  to  a  virtual  address  and  load  the  data  there. 
In  a  product,  the  TX  descriptor  ring  should  be  prepared  every  time  by  the  SMM  code 
before  transmitting  the  packet.  In  our  prototype,  since  we  don’t  have  the  source  code  of 
the  BIOS,  we  used  the  loader  to  load  the  TX  descriptor. 

Finally,  we  built  a  debugging  interface  for  the  SMM  code  on  the  physical  machine. 
We  use  the  reserved  physical  memory  to  pass  the  information  between  the  SMM  code 
and  the  normal  OS.  This  interface  is  also  used  to  measure  the  performance  of  the  SMM 
code  as  we  will  discuss  in  Section  6. 

6  Evaluation 

To  validate  the  correct  operation  of  HyperCheck,  we  first  verified  the  properties  that 
need  to  hold  for  us  to  be  able  to  protect  the  underlying  code  as  we  discussed  in  Sec¬ 
tion  4.2.  Then,  we  tested  the  detection  for  hypervisor  rootkits  and  measured  the  opera¬ 
tional  overhead  of  our  approach.  We  have  worked  on  two  testbeds:  testbed  1  is  mainly 
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used  for  HyperCheck-I  and  also  as  the  monitor  machine  for  HyperCheck-II.  Testbed  2 
uses  HyperCheck-II  to  produce  the  plotted  performance  overhead  on  the  real  hardware. 
Testbed  1  was  equipped  with  a  Dell  Precision  690  with  8GB  RAM  and  one  3.0GHz 
Intel  Xeon  CPU  with  two  cores.  The  host  operating  system  was  CentOS  5.3  64bit.  The 
QEMU  version  was  0.10.2  (without  kqemu).  The  Xen  version  was  3.3.1  and  Domain 
0  was  CentOS  5.3  32bit  with  PAE.  Testbed  2  was  a  Dell  Optiplex  GX  260  with  one 
2.0GHz  Intel  Pentium  4  CPU  and  512MB  memory.  Xen  3.1  and  Linux  2.6.18  was  in¬ 
stalled  on  the  physical  machine  and  the  Domain  0  is  CentOS  5.4. 

6.1  Verifying  the  static  property 

An  important  assumption  is  that  the  control  data  and  respective  code  are  statically 
mapped  into  the  physical  memory.  We  used  a  monitoring  module  designed  to  detect 
legitimate  control  data  and  code  modifications  throughout  the  experiments.  This  en¬ 
abled  us  to  test  our  approach  against  data  changes  and  self-modifying  code  in  the  Xen 
hypervisor  and  Domain  0.  We  also  tested  the  static  properties  of  Linux  2.6  and  Win¬ 
dows  XP  32bit  kernels.  In  all  these  tests,  the  hypervisor  and  the  operating  systems  are 
booted  into  a  minimal  state.  The  symbols  used  in  the  experiments  are  shown  in  Table  1. 
During  the  tests,  we  found  out  that  during  boot  the  control  data  and  the  code  changes. 
For  example,  the  physical  memory  of  IDT  is  all  0  when  the  system  first  boots  up.  But 
after  several  seconds,  it  becomes  non-zero  and  static.  The  reason  is  that  the  IDT  table 
is  initialized  later  in  the  boot  process. 


Table  1:  Symbols  for  Xen  hypervisor.  Domain  0,  Linux  and  Windows 


System 

Symbol 

Use 

Xen 

idtjable 

Hypervisor's  Interrupt  Descriptor  Table 

hypercalLtable 

Hypervisor's  Hypercall  Table 

exception table 

Hypervisor’s  Exception  Table 

_stext 

Beginning  of  hypervisor  code 

etext 

End  of  hypervisor  code 

DomO 

sys call table 

Domain  0’s  System  Call  Table 

_text 

Beginning  of  Domain  0’s  kernel  code 

_etext 

End  of  Domain  0’s  kernel  code 

Linux 

idtJable 

Kernel’s  Interrupt  Descriptor  Table 

sys call table 

kernel’s  System  Call  Table 

_text 

Beginning  of  kernel  code 

etext 

End  of  kernel  code 

Windows 

PCR-^idt 

Kernel's  Interrupt  Descriptor  Table 

KiServiceTable 

Kernel’s  System  Call  Table 

6.2  Detection 

To  verify  whether  HyperCheck  can  detect  attacks  against  the  hypervisor,  we  imple¬ 
mented  DMA  attacks  [40]  on  Xen  hypervisor  and  then  tested  HyperCheck-I’s  response 
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on  testbed  1 .  We  ported  the  HDD  DMA  attacks  to  modify  the  Xen  hypervisor  and  Do¬ 
main  0.  There  are  four  attacks  to  Xen  hypervisor  and  two  attacks  to  Domain  0.  We  also 
modified  the  pcnet  network  card  in  QEMU  to  perform  the  DMA  attack  from  the  hard¬ 
ware  directly.  The  modified  pcnet  NIC  is  used  to  attack  Linux  and  Windows  operating 
systems.  There  are  three  attacks  to  Linux  2.6.18  kernel  and  two  attacks  to  Windows 
XP  SP2  kernel,  each  targeting  one  control  table  or  the  code.  They  can  modify  the  IDT 
table  and  other  tables  of  the  kernel.  HyperCheck-I  correctly  detected  all  these  attacks 
by  reporting  the  contents  of  memory  in  the  target  machine  are  changed. 


6.3  Monitoring  overhead 


packet  size(  K  bytes ) 


Fig.  3:  Network  overhead  for  variable 
packet  size. 


Fig.  4:  Network  overhead  for  variable  data 
size. 


The  primary  source  of  overhead  is  coming  from  the  transmission  of  the  memory 
contents  to  the  external  monitoring  machine.  In  addition,  to  ensure  the  memory  con¬ 
tents  have  not  been  tampered  with,  HyperCheck  needs  to  remain  in  SMM  and  wait  until 
the  NIC  finished.  Otherwise,  the  attacker  may  control  the  OS  and  modify  the  memory 
contents  or  the  transmit  descriptor  in  the  main  memory  while  transmitting.  Initially, 
we  measured  the  time  to  transmit  a  single  packet  varying  its  payload  size.  The  packet 
flushed  out  when  the  Transmit  Descriptor  Head  register  (TDH)  is  equal  to  Transmit 
Descriptor  Tail  register  (TDT).  We  calculated  the  elapsed  time  using  the  rdtsc  in¬ 
struction  to  read  the  time  stamp  before  and  after  each  operation.  As  expected,  the  time 
linearly  increases  as  the  size  of  the  packet  increases. 

Next,  we  measured  the  bandwidth  by  using  different  packet  sizes  to  send  out  a  fixed 
amount  of  data:  2881  KB  memory  (the  size  of  Xen  code  plus  Domain  0  code).  The  result 
is  depicted  in  the  Figure  3:  when  the  packet  size  is  less  than  7  KB,  the  time  required 
to  send  the  data  similar  to  a  constant  value.  When  the  packet  size  becomes  8KB,  the 
overhead  increases  dramatically  and  it  remains  high.  The  reason  is  that  the  internal  NIC 
transfer  FIFO  is  16KB.  Therefore,  when  the  packet  size  becomes  8KB  or  larger,  the 
NIC  cannot  hold  two  packets  in  the  FIFO  at  the  same  time  and  this  introduces  delay. 
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Fig.  5:  Overhead  of  the  operations  in  SMM 

Since  HyperCheck  can  be  used  to  monitor  different  sized  hypervisors  and  OSes, 
we  measured  the  time  required  to  send  different  amount  of  data  and  the  results  are  in 
Figure  4.  In  this  set  of  experiments,  we  use  7KB  as  the  packet  size  since  it  introduced 
shortest  delay  in  our  testbed.  We  can  see  that  the  time  also  nearly  linearly  increased  with 
the  amount  of  memory.  In  addition  to  PCI  scanning,  HyperCheck  also  triggers  SMI 
interrupt  every  one  second  and  checks  the  registers  in  SMM.  To  measure  the  overall 
overhead  of  entering  SMM,  executing  SMM  code  and  return  from  SMM,  we  wrote  a 
kernel  module  running  in  Domain  0. 

The  tests  were  conducted  on  testbed  2  (HyperCheck-II)  and  each  test  is  repeated 
many  times.  Here  we  present  the  average  of  the  results.  The  overall  time  is  composed 
of  four  parts.  First,  the  time  taken  to  XOR  the  data  with  the  secret  key.  Second,  the  time 
to  access  the  memory.  Third,  the  time  to  configure  the  card  and  switch  from  protected 
mode  to  SMM  and  back.  Finally,  the  time  to  send  out  the  data  through  the  NIC.  To  find 
out  how  much  time  was  spent  in  each  part,  we  wrote  two  more  test  programs.  One  is  a 
dummy  SMM  code  which  does  nothing  but  just  returns  from  SMM  to  CPU  protected 
mode.  The  other  one  does  not  access  the  main  memory  but  just  use  the  registers  to  sim¬ 
ulate  the  verification  of  IDTR  and  CR3.  Then  we  tested  the  running  time  for  these  two 
SMM  codes.  From  the  first  one,  we  can  get  the  time  for  switching  between  protected 
mode  and  SMM  and  then  switch  back.  From  the  second  one,  we  can  get  the  time  for 
the  CPU  computation  part  of  the  verification  of  IDTR  and  CR3. 

The  results  are  presented  in  Figure  5.  The  most  of  the  time  is  spent  in  sending  the 
data,  which  is  73  Million  cycles.  Next  is  the  time  to  accessing  the  main  memory  :  5.28 
Million  cycles.  Others  took  a  very  small  portion.  The  total  time  is  80  Million  cycles. 
Since  the  CPU  of  the  testbed  2  is  2  GHz.  Therefore,  the  SMM  code  consumes  4.0%  of 
the  CPU  cycles,  and  takes  40  ms. 

We  also  measured  the  code  size  of  our  SMM  code,  which  is  just  about  300  Bytes. 
On  the  monitor  machine,  the  overhead  for  reading  the  memory  contents  and  comparing 
them  with  previous  state  took  230  ms,  including  49  ms  for  only  comparing  the  data. 
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Fig.  6:  Overhead  of  the  XOR  data  in  SMM 


Note  it  is  possible  to  reduce  the  time  for  reading  the  memory  contents  from  the  file,  if 
we  use  pipe  or  other  memory  sharing  based  communication  between  tcpdump  and  the 
perl  script. 


Execution  Time(ms) 


Code  base 

Size(MB) 

HC 

SMM 

TPM 

Linux 

2.0 

31 

203 

1022 

Xen+DomO 

2.7 

40 

274 

>1022 

Window  XP 

E8 

28 

183 

>  972 

Hyper-V 

2.4 

36 

244 

>1022 

VMWare  ESXi 

2.2 

33 

223 

>1022 

Table  2:  Time  overhead  of  HyperCheck  and  other  methods 


In  contrast,  previous  research  suggests  using  SMM  to  read  the  memory  and  hashing 
it  on  the  target  machine.  We  call  this  SMM  only  method.  To  compare  our  approach  with 
SMM  only  method,  we  wrote  a  program  to  XOR  the  memory  in  SMM  with  different 
sizes.  The  result  is  shown  in  Figure  6. 

The  time  for  XOR  data  is  linearly  increased  with  the  amount  of  data  and  typically 
uses  hundreds  of  Million  CPU  cycles.  Also,  we  compare  our  approach  with  a  TPM 
based  approach  [23]  which  can  also  be  used  to  monitor  the  integrity  of  the  kernels.  The 
result  is  shown  in  the  Table  2.  HC  stands  for  HyperCheck.  We  can  see  that  the  overhead 
of  HyperCheck  is  one  magnitude  lower  than  SMM-only  and  TPM  based  method.  For 
SMM-only,  it  has  to  hash  the  entire  data  to  check  its  integrity,  while  HyperCheck  only 
hashes  a  random  portion  of  the  data  and  then  sends  the  entire  data  out  using  an  Ethernet 
card.  For  TPM  based  method,  the  most  expensive  operation  is  TPM  quote,  which  alone 
took  972  ms.  Note  that  the  test  machine  of  TPM  based  method  is  better  than  our  testbed 
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Memory  Registers  Overhead 


HyperCheck 

X 

X 

Low 

SMM 

X 

X 

High 

PCI 

X 

Low 

TPM 

X 

X 

High 

Table  3:  Comparison  between  HyperCheck  and  other  methods 


2.  An  overall  comparison  between  HyperCheck  and  other  methods  is  shown  in  Table  3. 
We  can  see  that  only  HyperCheck  can  monitor  both  memory  and  registers  with  low 
overhead. 


7  Security  Analysis  &  Limitations 

HyperCheck  aims  to  detect  the  modifications  to  the  control  data  and  the  codes  of  the 
hypervisors  or  OS  kernels.  These  kinds  of  attacks  are  realistic  and  have  a  significant 
impact  on  the  system.  HyperCheck  can  detect  these  attacks  by  using  an  Ethernet  card 
to  read  the  physical  memory  via  DMA  and  then  analyze  it.  For  example,  if  the  attack¬ 
ers  control  the  hypervisor  and  make  some  modifications,  HyperCheck  can  detect  that 
change  by  reading  the  physical  memory  directly  and  compare  it  with  previous  pristine 
value. 

In  addition,  HyperCheck  also  uses  SMM  to  monitor  CPU  registers,  which  provides 
further  protection.  Some  previous  research  works  only  rely  on  the  symbol  table  in  the 
symbol  file  to  find  the  physical  address  of  the  kernel  code  and  data.  Nonetheless,  there 
is  no  binding  between  the  addresses  in  the  symbol  table  and  the  actual  physical  address 
of  these  symbols  [22],  For  example,  one  potential  attack  is  to  modify  the  IDTR  register 
of  CPU  to  point  to  another  address.  Then  the  malware  can  modify  the  new  IDT  table, 
keeping  the  old  one  untouched.  Another  potential  attack  is  to  keep  the  IDTR  register 
untouched,  but  modify  the  page  tables  of  the  kernel  so  that  the  virtual  address  in  the 
IDTR  will  actually  point  to  a  different  physical  address.  HyperCheck  can  detect  these 
cases  by  checking  CPU  registers  in  SMM.  In  SMM,  HyperCheck  read  the  content  of 
IDTR  and  CR3  registers  used  by  the  operating  system.  IDTR  should  never  change  after 
booting.  If  it  changed,  SMM  will  send  a  warning  through  the  Ethernet  card  to  the  mon¬ 
itor  machine.  From  CR3,  HyperCheck  can  find  the  actual  physical  address  given  the 
virtual  ones.  The  offset  between  the  virtual  addresses  and  the  physical  addresses  should 
be  static.  If  some  offsets  changed,  HyperCheck  will  generate  a  warning  too.  Moreover, 
PCI  devices  including  the  Ethernet  card  alone  can  be  cheated  to  get  a  different  view  of 
the  physical  memory  [32].  With  SMM,  we  could  avoid  this  problem  by  checking  the 
corresponding  settings  in  SMM. 

The  network  card  driver  of  HyperCheck  is  put  into  the  SMM  code  to  avoid  ma¬ 
licious  modifications.  Also,  to  prevent  replay  attacks,  we  use  a  key  to  hash  a  portion 
of  the  data  randomly  and  then  send  them  out  to  the  analysis  module.  Since  the  key  is 
private  and  locked  in  the  SMRAM,  the  attacker  cannot  get  it  and  cannot  generate  the 
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same  hash.  Attacker  can  still  try  to  disable  the  Ethernet  card  or  the  SMM  code,  but  we 
can  detect  it  through  an  out-of-band  monitor,  such  as  Dell  remote  access  controller. 

In  addition,  the  attacker  may  try  to  launch  a  fake  reboot  attack  to  get  a  private 
key  from  the  monitor  machine.  It  can  mimic  the  SMM  NIC  driver  and  send  a  request 
for  a  new  key.  For  this  event,  we  have  two  options:  first,  we  could  use  Trusted  Platform 
Module  (TPM)  based  remote  attestation  to  verify  the  running  state  of  the  target  machine 
[23],  We  only  need  to  verify  whether  the  OS  has  been  started  or  not.  If  it  is  already 
started,  the  monitor  machine  should  refuse  to  send  the  key.  If  the  target  machine  does 
not  have  a  TPM,  the  second  method  is  to  send  another  reliable  reboot  signal  to  the  target 
machine  when  it  asks  for  the  key  to  make  sure  the  SMM  code  is  running. 

However,  HyperCheck  also  has  its  limitations.  It  cannot  detect  the  changes  which 
happen  between  the  two  consecutive  memory  and  register  scans.  Although  the  time 
window  between  the  scans  is  just  one  second  in  the  current  prototype,  malware  can  still 
potentially  make  some  changes  in  the  time  interval  and  restore  it  before  the  next  scan. 
To  address  this  problem,  we  could  randomize  the  scan  interval  to  increase  the  chances 
for  detection.  In  addition,  we  could  use  high  bandwidth  devices,  such  as  PCI  Express, 
which  is  able  to  reach  5GT/s  transfer  rate  [29],  to  minimize  the  scan  interval. 

In  addition,  if  the  memory  mappings  of  the  hypervisor  do  not  hold  the  three  proper¬ 
ties  (linear  mapping,  persistence  and  static  nature),  the  current  version  of  HyperCheck 
cannot  deal  with  it.  We  will  try  to  address  these  problems  in  the  future. 

8  Conclusions 

In  this  paper,  we  introduced  HyperCheck,  a  hardware-assisted  tamper  detection  frame¬ 
work.  Hypercheck  is  designed  to  protect  the  code  integrity  of  software  mnning  on  com¬ 
modity  hardware.  This  includes  VMMs  and  Operating  Systems.  To  achieve  that,  we 
rely  on  the  CPU  System  Managed  Mode  (SMM)  to  securely  generate  and  transmit  the 
full  state  of  the  protected  machine  to  an  external  server.  HyperCheck  does  not  rely  on 
any  software  running  on  the  target  machine  beyond  BIOS.  Moreover,  HyperCheck  is 
robust  against  attacks  that  aim  to  disable  or  block  its  operation. 

To  demonstrate  the  feasibility  of  our  approach,  we  implemented  two  prototypes  one 
using  QEMU  and  another  one  using  an  Ethernet  card  on  a  commodity  x86  machine. 
Our  experimental  results  indicate  that  we  can  successfully  identify  alterations  of  the 
control  data  and  the  code  on  many  existing  systems.  More  specifically,  we  tested  our 
approach  in  part  of  the  Xen  hypervisor,  the  Domain  0  in  Xen,  and  the  control  structures 
of  other  operating  systems,  such  as  Linux  and  Windows.  HyperCheck  operation  is  rel¬ 
atively  lightweight:  it  can  produce  and  communicate  a  scan  of  the  state  of  the  protected 
software  in  less  than  40ms. 
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